Web services are a distributed systems technology where network endpoints exchange a specific form of XML document called a SOAP envelope which may contain a body element containing a request, response, or fault element, together with an optional header element containing routing or security information. In the broader sense, a SOAP envelope also may be designated as a SOAP message. Further details about SOAP can be found in “SOAP Version 1.2 Part 0 Primer W3C Recommendation”. SOAP allows the existence of so-called network intermediaries. An intermediary may be a router or a firewall. SOAP may allow these intermediaries to process a SOAP envelope, by adding or modifying headers. In the following such a processing will be stated as an extension of the SOAP envelope. Examples of web services include Internet-based services for ordering goods or invoking search engines, and intranet-based services for linking enterprises as described in “A Semantics for Web Services Authentication, Karthikeyan Bhargavan, Cedric Fournet, Andrew D. Gordon, February 2004, Technical Report, MSR-TR-2003-83”.
Because of its simplicity, standardization and platform independent nature, a lot of business organizations have embraced web service technology for an integration of data, system and application inside and outside their organization boundary. Due to this growing adoption by different organization, security of web services became a vital issue.
One way for securing SOAP exchanges can be relying on a transport level security like Transport Layer Security/Secure Sockets Layer (TLS/SSL). This might work well in many situations, however it may not be suitable for every situation due to its point-to-point security nature. TLS/SSL creates a security tunnel between respective two communication end points. Integrity and confidentiality of a SOAP message may be ensured as long as the message exists inside this tunnel but not subsequently in files or databases, and they may not match the security requirements of a corresponding application. For instance, client authentication may be performed by the application rather than by TLS/SSL. Besides, SSL does not fit SOAP's message-based architecture: intermediaries cannot see the contents of the tunnel, and so cannot route or filter messages. This phenomenon is further described in “A Semantics for Web Services Authentication, Karthikeyan Bhargavan, Cédric Fournet, Andrew D. Gordon, February 2004, Technical Report, MSR-TR-2003-83”.
To overcome the above limitation of transport level security, Microsoft, along with IBM and VeriSign came up with a new security framework that can be used to achieve end-to-end security in web service communication. This security framework is named as WS-Security (Web Service-Security). WS-Security specifies how security elements like encrypted data, signed data and security tokens like username, X.509 certificate, etc., can be embedded in a SOAP message which is the usual vocabulary for web service communication.
After the emergence of WS-Security a number of standards on top of this have been proposed to take care of different security aspects of web service communication. WS-Security Policy along with WS Policy attachment provide a standard way to specify the security requirements of a web service. WS-Secure conversation specifies ways for securing not only a single SOAP message but also a whole session between a client and a server. WS-Trust specifies how security tokens can be requested, issued and verified.
Despite all of these security specifications, web services may still be vulnerable to a class of attacks, first described by Needham and Schroeder “R. Needham and M. Schroeder. Using encryption for authentication in large networks of computers. Commun. ACM, 21(12):993-999, 1978” and first formalized by Dolev and Yao “D. Dolev and A. Yao. On the security of public key protocols. IEEE Transactions on Information Theory, IT-29(2): 198-208, 1983”, where an attacker may intercept, compute, and inject messages, but without compromising the underlying cryptographic algorithms. In the terminology of web service security, this sort of attack is called XML rewriting attacks, as opposed to attacks on web services implementations, such as buffer overruns or Structured Query Language (SQL) injection. As described in “K. Bhargavan, C. Fournet, and A. D. Gordon. Verifying policy-based security for web services. In 11th ACM Conference on Computer and Communications Security (CCS '04), pages 268-277, October 2004”, WS-Security adopted XML Digital Signature and XML Encryption mechanism, designed for a general XML document, to provide integrity and confidentiality in SOAP communication. XML Digital Signature refers to a signed object of an XML document in a way that does not take care of the location of that object. SOAP extensibility model allows a SOAP message to contain a SOAP header element that is not recognized by a receiver. WS-Security allows multiple security headers to exist in the same SOAP message. All of these features along with the weakness of XML Digital Signature work as a weapon for performing an XML rewriting attack on SOAP messages.
WS-Security Policy, if used correctly, may be used to guard against an XML rewriting attack. However, most of the policy configuration files are hand written. Therefore, they may be error prone. Moreover, due to the flexibility provided by SOAP extensibility model it is hardly possible to prevent attacks where the corresponding attacker moves a signed element under another unknown element.
The word cryptography means the art of secret writing. It is a procedure of transforming information from its original format to a format that is not easily understandable. To get back the original information from the transformed one a secret method has to be used. Cryptography may be used for communication between participants in a way that prevents other from reading it.
In the terminology of cryptography a message that is to be transformed is called the plaintext and the resulting message generated after transformation is called the ciphertext. The mechanism of transforming a plaintext into ciphertext is called encryption and the mechanism of getting back the plaintext from the ciphertext is called decryption.
Two types of cryptographic procedure may be commonly used:
i) Symmetric key cryptography
ii) Public key cryptograph
To secure a communication using symmetric key cryptography, parties involved in the communication share a secret key. This shared key is used both for encryption and decryption of the message exchanged among the communicating parties. As the same key is used for both encryption and decryption, this cryptographic procedure is called symmetric key cryptography. It is also may be referred to as shared key cryptography.
The main idea of public key cryptography is that a key will be composed of two parts. If a message is encrypted using one part of a key, then it can be decrypted using only the other part. In the terminology of public key cryptography the two parts of a key are called public key and private key. The public key, as its name implies, may be published in public. That means anyone can know it. However, the private key, as its name implies, may be totally private. That is only the owner of the key will know it.
Digital Signature is a mechanism for signing a document electronically. It may be used by a recipient of a document to authenticate the identity of the corresponding sender of the document. It also may be used to check the integrity of the received document. By verifying the integrity of the received document the receiver can be assured that the document has not been forged by an adversary on its way from the respective sender to the receiver.
When a sender wants to send a digitally signed message “m” to a receiver, it may go through the following operations:    i) It generates a message digest MD using an appropriate hash method H of the plaintext message m. The message digest MD of a plaintext message x is represented by H(x). So the sender first generates MD=H(m) for the plaintext message m.    ii) It then encrypts the message digest MD using its own private key and generates MD-1, where MD-1 represents the encrypted message digest.    iii) It appends the encrypted message digest MD-1 with the plaintext message m and generates the message m|MD 1.    iv) It sends m|MD-1 to the receiver.
When a receiver receives a message M=m|MD-1 from a sender, it goes through the following operations:    i) It extracts the whole message M=m|MD-1 into its sub-components. That means that it divides the whole message M into m and MD-1.    ii) It generates a message digest MD_1 of the received message m.    iii) It decrypts the received encrypted message digest MD-1 and generates MD_2.    iv) It compares the two message digest MD_1 and MD_2. If the two message digests are the same, then the message has not been forged on its way and the sender is the one who it supposed to be. Otherwise either the message has been forged or the identity of the sender is not valid.
One issue in using secret key cryptography is the distribution of the secret key among the communicating parties. If a person called Bob wants to send a message to another person called Alice using symmetric key cryptography, then both Bob and Alice need to share a common secret key. However, this secret key has to be exchanged between them in a secure way. If this secret key is intercepted by a middleman during the exchange, the communication between Bob and Alice with this secret key will not remain secret anymore. A middleman might intercept all the messages exchanged between them and would be able to decrypt and read the messages.
To overcome this key management issue, the idea of public key cryptography emerged. In public key cryptography, a key consists of two parts, namely a public part and a private part. The public part of the key may be known to all. However, the private part may only be known to the owner. Furthermore, if a message is encrypted using a public or private key, then the message can only be decrypted using the respective private or public key. This idea has immensely simplified the key management problem. Now, the participants don't have to exchange any secret key. However, all they have to know is the public key of the party to whom he/she wants to send a secret message. And as this public key may be known to all, the sender can just grab the public key and start the communication.
One of the limitations of the existing public key cryptographic procedure is that they are computationally expensive. Digital envelope is a framework, which tries to combine the advantages of the above mentioned cryptographic services.
A digital envelope may include a message encrypted using a secret key cryptography and an encrypted secret key. Normally, digital envelope may use public key cryptography to encrypt the secret key.
In the following, it is supposed that a sender wants to send a message M to a receiver using digital envelope. Then he will go through the following operations:    i) The sender may choose a random secret key to encrypt the message M.    ii) The sender may encrypt the message using the secret key chosen.    iii) The sender may take the receiver's public key to encrypt the secret key.    iv) The sender may encrypt the secret key with the receiver's public key.    v) The sender may append the encrypted secret key with the encrypted message and will send it to the receiver.
When a receiver receives the message it may go through the following operations:    i) The receiver may extract the message into its sub parts. That is, it may retrieve the encrypted message and the encrypted secret key.    ii) The receiver may decrypt the encrypted secret key using its private key to get the secret (symmetric) key.    iii) The receiver may use the decrypted symmetric key to decrypt the encrypted message to get the message M.
The digital envelope has the following advantages over the symmetric and public key cryptographic procedure:    i) It may simplify the key management procedure, which is the main limitation in using symmetric key cryptography.
It increases the performance. Now the whole message, which can be of variable length, need not be encrypted using Public key cryptography. However, the message itself is encrypted using a secret key and the secret key, which is usually much smaller in size than the message, is encrypted using public key cryptography.
A so-called hash also may be referred to as a message digest. It is a one-way function that takes as input a variable length message and generates a fixed length hash value. This function can be called one-way as it is possible to generate output y for input x with this function; however, it is not practically possible to get back input x from output y.
The hash of a message m is denoted in the following as h(m). Then h(m) may contain the following properties:    i) h(m) may be relatively easy to compute for any given message m. That means it may not consume a lot of processing time to compute the hash h(m) for any message m.    ii) Given h(m), there is no way to find an m that hashes to h(m) in a way that is substantially easier than going through all possible values of m and computing h(m) for each one.    iii) From the definition of hash it may be obvious that more than one message m will map to the same hash value h(m). However, it should be computationally infeasible to find two messages that map to the same hash value.
Hashing has an important role in security world. It may be used to check the integrity of a transmitted message. It also may be used to verify the authentication of the respective sender.
There are a number of hashing algorithms that may be used (e.g., SHA-1, SHA-224, SHA-256, SHA-512, etc). These hashing algorithms are called secure hash algorithms. The numbers associated with the name of the hash algorithms indicate the length of the output in bits. For instance, SHA-256 means, this algorithm will take a variable length message as input and will produce a 256 bit message digest.
SOAP (Simple Object Access Protocol) is a lightweight protocol for exchanging structured data in a decentralized and distributed environment. As described in “SOAP Version 1.2 Part 0 Primer W3C Recommendation,” SOAP provides an extensible messaging framework using XML technologies. It defines a message construct that can be exchanged over a variety of underlying protocols. The framework has been designed to be independent of any particular programming model and other implementation specific semantics.
The SOAP messaging framework may include the following, which will be described subsequently in this section.    i) SOAP Message Construct    ii) SOAP Processing Model    iii) SOAP Extensibility Model    iv) SOAP Protocol Binding    v) SOAP Message Construct
A SOAP message may be encoded as an XML document. Each SOAP message may include one root element, which is called <Envelope> element. The <Envelope> element contains the following sub elements as its children.    i) An optional <Header> element.    ii) A mandatory <Body> element.
A <Header> element may include data that is not an application payload. This element is intended to be processed by zero or more intermediaries along the path of the SOAP message from initial sender to ultimate receiver. The <Header> element may include zero or more <HeaderBlock> as its child element. Each <HeaderBlock> within the <Header> element may realize zero or more features. For instance, to realize the security feature, which is not specified by the Core SOAP Processing model, a <Security> header block may be used as a sub element of the <Header>.
The <Body> element may include the application payload. The <Body> element may be processed by the ultimate receiver of the SOAP message.
The SOAP processing model as described in “SOAP Version 1.2 Part 0 Primer W3C Recommendation” specifies how a SOAP receiver processes a SOAP message. SOAP specifies a distributed processing model. The initial sender generates a SOAP message, which is reached to the ultimate SOAP receiver via zero or more so-called SOAP nodes. The distributed processing model of SOAP can be used to support a number of different MEP (Message Exchange Pattern) like One-Way Message, Peer-to-Peer conversation or Request/Response interaction.
When a SOAP message passes on its way from the initial sender to the ultimate receiver, the SOAP nodes, called in the following intermediaries, between the sender and the receiver along with the receiver node process this SOAP message conforming to the SOAP Processing model Specification.
After the reception of a SOAP Message, a SOAP node tries to determine the parts of that message that are targeted to it. This determination may be done by the use of a “role” attribute of a SOAP header block.
If a SOAP node finds that the value of the role attribute of a header block is the role that it assumes, then this block is targeted to it. A role is specified in the header block using URI (Uniform Resource Identifier). SOAP defines 3 standard roles that can be assumed by a SOAP node. These standard roles are indicated as “Next”, “Ultimate Receiver” and “None”.
Beside these standard SOAP defined role attributes, an application may also define its own application specific role.
Once the SOAP node finds out all the parts of a SOAP message targeted to it, it will try to process them. SOAP nodes may not be obliged to process or understand all the message parts targeted to it. SOAP specifies another attribute “misunderstand” for the header block. If this attribute's value is true in a header block, the targeted SOAP node may be obliged to understand and process that block. This sort of header block is called a mandatory header block. If a SOAP node finds a mandatory header block targeted to it, however, it cannot process it according to the specification of the header block, it will generate a SOAP fault and will cease the relaying of this message further.
After the successful processing of a header block, colloquially the SOAP node removes the block from the outgoing message. However, there are circumstances where the node might have to retain the block in the outgoing message. One of the reasons for retaining a header block in the outgoing message is the semantics of the header block. That is if the specification of the header block mandates the presence of this header block in the forwarded message. Another reason is, if the header block contains the “relay” attribute with a value of true. As it is said before, a SOAP node is not obliged to process all the header blocks targeted to it.
However, even if it does not process a non-mandatory header block targeted to it, it may remove the block from the outgoing message. If a non-mandatory header block is wanted to be processed by the first SOAP node that assumes a particular role and understands this header block, this relay attribute is to be used in that header block with a value of true. In this case a SOAP node that assumes the role specified in the header block, even though it cannot process the block, it may retain it in the outgoing message.
A SOAP message can be exchanged between two SOAP nodes using a number of different protocols. For instance, it can be exchanged using hypertext transfer protocol (HTTP), or using simple mail transfer protocol (SMTP) or even using transmission control protocol (TCP) or user datagram protocol (UDP). SOAP protocol binding specifies how a SOAP message can be exchanged between two adjacent SOAP nodes using an underlying protocol.
When a SOAP sender needs to send a SOAP message to another SOAP node, it first creates an abstract representation of the message using SOAP message elements and attributes. To send this abstract SOAP message over the wire to another SOAP node, the message may be serialized in a specified way so that the receiver can deserialize it. SOAP protocol binding describes how a SOAP message will be serialized and deserialized for sending over the wire using an underlying protocol.
Besides providing a concrete realization of a SOAP message for sending over the wire from one SOAP node to another, SOAP protocol binding provides a mechanism for supporting features that might be needed by an application. A feature specifies certain functionality provided by protocol binding. A feature can be referenced by the application using uniform resource identifier (URI).
In order to secure web service communication, multiple security technologies may be provided to secure Internet resources. One of the most widely used and proven security technologies is SSL (Secure Sockets Layer). Many online shopping sites use SSL to secure their resources. As many of the web services may use HTTP for communication, it may be possible to use SSL for securing web services. Unfortunately, in the Web services world however, SSL may have some limitations.
SSL/TLS may provide point-to-point security. SSL establishes a secure pipe between two adjacent communicating nodes and then transfers data using this pipe. While the data is in the pipe it is secured. However, once data came out of that pipe, it is in clear. That means the security context only exists between two adjacent nodes. Hence if a message needs to pass one or more hops before reaching the ultimate destination, the message may be in clear at some point of time in each of the hop. Therefore, if an attacker can get access in one of these hops, he can easily read or modify the message.
According to SOAP specification, a message can traverse one or more intermediaries before it is reached to its ultimate destination. Therefore, SSL is not suitable for securing this communication. To secure a web service the message is to be secured not the link. That means, the security context for a web service must exist end-to-end. End-to-end security is also called message level security as the security information for a message is embedded in the message itself.
WS-Security is a specification that specifies how message level security can be achieved. SSL is bound to HTTP. SOAP messages can be exchanged using a wide variety of protocols like FTP, SMTP, TCP, and HTTP etc. However, SSL can only be used to secure HTTP communication. Therefore, SSL is not suitable for securing web service communication.
SSL does not support partial visibility. Partial visibility means that part of a message will be encrypted and the rest will be in clear. SSL encrypts the whole message. However, partial visibility is a vital necessity in web service communication. According to SOAP specification, a sender can direct different parts of a message to different SOAP nodes. The discretion of the sender determines which part of the message will be encrypted, which part will be signed and which part will be in clear. SSL does not provide this provision, therefore it may not be suitable for web service communication security.
Due to the above mentioned limitations of traditional transport level security, there was a need for a different type of security mechanism for web service communication. Therefore, in April 2002 Microsoft, IBM and VeriSign proposed a security specification for web service communication. In April 2004, that standard was established as an approved OASIS open standard as further described in “Securing Web Services with WS-Security: Demystifying WS-Security, WS-Policy, SAML, XML Signature, and XML Encryption by Jothy Rosenberg, David Remy” for securing SOAP exchange. This it standard is known as WS-Security.
XML Digital Signature as described in “XML-Signature Syntax and Processing, W3C Recommendation 12 Feb. 2002” provides a mechanism for signing partial or chosen elements of an XML document. This signature can be used by the receiver of the message for verifying the integrity of the message and the authenticity of the sender.
A number of different types of resources can be signed using XML Digital Signature. For instance, character-encoded data like HTML, binary-encoded data like Image, XML-encoded data can be signed using a single XML Signature.
At the time of XML Signature validation, the data object that has been signed may need to be accessible. XML Signature indicates the location of the signed data object in one of the following ways:                The signed data object is referenced using a reference URI within the XML Signature element.        The signed data object is a child of the XML Signature element. That means the signed object is inside the XML Signature element.        The signed data object contains the XML Signature element, that contains its signature, within it. That is the signed data object is the parent of its Signature element.        
The Signature generation process for XML Digital Signature may be broadly divided into two steps.
1. Reference Generation
2. Signature Generation
1. Reference Generation:
In this step, a reference element is created for each data object that has to be signed. First, a transformation is performed on the data object, then the digest value of the transformed data object is calculated and finally a reference element is created which references the data objects to be signed and may include the following elements:
i) Transformation elements to specify the applied transformation on the data object.
ii) Algorithm that is used to generate the digest value of the data object.
iii) The digest value of the data object.
2. Signature Generation:
In this step a <SignedInfo> element is created which includes the list of <ReferenceElement> (from the Reference Generation step), a <SignatureMethod> element and a <CanonicalizationMethod> element. The whole <SignedInfo> element is canonicalized using the method specified within the <CanonicalizationMethod> Element. After that a signature value is generated over this canonicalized <SignedInfo> element using the algorithm specified under the <SignatureMethod> element. Finally a <Signature> element is created which includes the <SignedInfo> element(s), a <KeyInfo> element and a <SignatureValue> element. The <KeyInfo> element represents the key used to generate the signature value, which is placed under the <Signature> element.
The signature validation procedure may be categorized in two operations:
1. Reference Validation
2. Signature Validation
1) Reference Validation:
In this step, the digest value for each referenced data object is checked for validity. First the <SignedInfo> element is canonicalized using the Canonicalization method specified under the <SignedInfo> element. Then, for each reference element the referenced data object is retrieved and a digest value is calculated on that data object using the digest method specified under the <Reference> Element. The resulting digest value is compared with the digest value specified under the <Reference> element. If these two values are same, then the verification proceeds for the second reference element. Otherwise, it generates an error message.
2) Signature Validation:
If the Reference Validation operation passed successfully, then follows the Signature Validation operation. In this step, the keying information, specified in the <KeyInfo> element of the <Signature> element, is retrieved possibly from an external source. Then, the Signature method is determined from the <SignatureMethod> element of the <SignedInfo> element. These two information, that is, Keying Information and Signature Method, are used to validate the Signature value specified under the <SignatureValue> element of the <Signature> element.
XML may represent information using a tree structure. XML Digital Signature allows non-contiguous objects of an XML dataset to be signed separately. The signed object may be referenced using an indirection (URI) by the reference element of the Signature. This indirect referencing does not give any information regarding the actual location of the signed object. Therefore, the signed object can easily be relocated and the Signature value will still remain valid. In cases where the location of the data object is important in the interpretation of the semantics associated with the data, this can be exploited by an adversary to gain unauthorized access to protected resources as further described in “An Advisor for Web Services Security Policies by Karthikeyan Bhargavan, Cedric Fournet, Andrew D. Gordon, Greg O'Shea at Microsoft Research”. This is a limitation of XML Digital Signature.
WS-Security is an extension of the already described SOAP Messaging framework. WS-Security specification does not provide any new security protocol itself. Instead, it specifies how the prevalent security technologies can be used to secure SOAP messages. Authentication, integrity and confidentiality are three features of any secure communication protocol. WS-Security specifies a standard way of achieving these features for SOAP messages. It provides a mechanism for attaching security tokens with SOAP messages. Security tokens along with other mechanisms can be used to authenticate a client. WS-Security does not restrict applications to use a particular form of security token. However, a wide variety of security token formats including binary security tokens like X.509 certificate or Koreros Ticket can be attached with SOAP messages using WS-Security standard. WS-Security provides a mechanism for encoding binary security tokens for attaching to a SOAP message.
Integrity of a SOAP message is provided using XML Digital Signature technology along with the Security token. Security token represents the key using which a portion of the SOAP message is signed. This key is referenced from the signature. As the SOAP message has to go through a number of intermediaries before it is reached to the receiver, it is perfectly valid for the intermediary to produce its own signature. WS-Security provides a way to attach multiple signatures in the same SOAP message. This Signature provides a way for the receiver and/or the intermediaries to ensure that a SOAP message has not been tampered on its travel path. WS-Security may not specify any particular signature technology to be used for signing a SOAP message. Instead, a variety of signature technology can be used to sign different portions of the same SOAP message.
In the same way, confidentiality of a SOAP message may be provided using an XML Encryption mechanism in conjunction with Security token. The security token represents the key by which a portion of the SOAP message has been encrypted. The security token is referenced from the encryption element. As with XML Signature, WS-Security provides a way to encrypt different portions of a SOAP message to be encrypted by different SOAP actors (receiver/intermediary) and they can use different encryption technology to pursue this.
There are some limitations which have to be considered:
1) WS-Security uses XML Digital signature for signing non-contiguous parts of a SOAP message. Therefore, the limitations of XML Digital signature are also applicable to WS-Security.
2) WS-Security allows multiple security headers (with the same name) to exist in the same SOAP message. This may create a pit fall and can be exploited by an attacker. It will be shown later how this feature can be exploited.
3) WS-Security does not propose any new security technology. However, it specifies how the existing security technology can be used to secure a SOAP message exchange.
4) WS-Security encompasses many other standards like XML Digital Signature, XML Encryption, X.509 certificates Kerberos ticket etc (“Securing Web Services with WS-Security: Demystifying WS-Security, WS-Policy, SAML, XML Signature, and XML Encryption by Jothy Rosenberg, David Remy”). For this reason, the specification became quite complex.
WS-Policy is a generalized grammar for describing the capabilities, requirements, and characteristics of a Web service. WS-Policy is not specific to any particular domain like Security, Reliable Messaging, Privacy or Quality of service. It can be used to express the requirements of a web service for a broad range of domain. However, WS-Policy does not itself specify how the policy will be associated with a particular web service. For this association, a separate specification WS-Attachment has emerged.
Before using a Web Service, the client may need to know the requirements of that service. For instance, a particular Web service might require that all the requests coming to it must satisfy at least one of the following requirements:
i) Each request must contain either a User Name token or a X.509 token or both.
ii) User Name token if present must be signed by AES algorithm.
iii) X.509 token if present must be signed by Triple DES algorithm.
The following excerpt shows how service requirements can be expressed using WS-Policy:
<Wsp: Policy Id=”Policy1” Name=”MyPolicy”> <Wsp:OneOrMore>  <wsp:All wsp:Preference=″100″/>   <wsse:SecurityToken TokenType=″wsse:UsernameToken″ />   <wsse:Algorithm Type=″wsse:AlgSignature″URI=″ http://www.w3.org/2000/09/xmlenc#aes″/>  </wsp:All>  <wsp:All wsp:Preference=″1″/>   <wsse:SecurityToken TokenType=″wsse:X509v3″ />   <wsse:Algorithm Type=″wsse:AlgEncryption″    URI=″http://www.w3.org/2001/04/xmlenc#3des-cbc″/>  </wsp:All> </wsp:OneOrMore></wsp:Policy>
The above shown excerpt represents a sample policy for a web service. A policy is actually a collection of policy assertions. A policy assertion asserts some requirements of a service that a client request must meet in order to use that service. The assertions are wrapped into a policy element. As it can be seen from the above shown excerpt, the policy element contains one policy operator <wsp:OneOrMore>. The policy operator can be used to create a quite complex policy, for instance a nested policy. In this example, only two policy operators are shown. There are other policy operators. The operator <wsp:OneOrMore> means that at least one of its child assertions must be applicable. This operator contains two <wsp:All> operators. This operator means that all of its assertions must be met by the request to be identified as valid. It is not mandatory to use a policy operator. All assertions can be directly specified as the child element of the root policy element. In this case, all of the child assertions must be met to get a service. In the excerpt above, each of the <wsp:All> operators contains two assertions within it. The first group of assertions specify that a request must contain a Username token and this token has to be signed by AES Signature algorithm. The second group of assertions specifies that a request must contain a X.509 token and it has to be encrypted using Triple DES Encryption algorithm. As these groups of assertions are embedded within an <wsp:OneOrMore> operator, this means at least one of those groups of assertions must be met to get a service protected by this policy file.
However, WS Policy standard may lack semantics. It provides a mechanism for describing the syntactic aspects of service properties. This introduces a limitation on the policy specification and policy intersection. For example, a provider may specify that its service supports a particular algorithm for the adjustment of data retransmission timeout value and a consumer may define a policy requiring a different algorithm. It might be possible to substitute the required algorithm by the provided algorithm, if they are compatible. However, the current standard does not support this kind of relationship identification. Thus, although it is possible, the interaction between the provider and the consumer may not occur as further described in “Semantics-enriched QoS Policies for Web Service interactions by Diego Zuquim Guimarães Garcia and Maria Beatriz Felgar de Toledo”.
As mentioned before, WS-Policy provides a general framework for representing web service's constraints and requirements. However, it does not specify any security assertion for any particular problem domain like reliable messaging or security. Each domain has its own specific assertion profile. WS-Security Policy as described in “Web Services Security Policy Language (WS-Security Policy)” specifies policy assertions to represent the security requirements of a web service.
WS-Security policy specifies a number of security assertions like Security Token assertion, Integrity assertion, Confidentiality assertion, Visibility assertion, Message Age assertion and a lot more.
Security Token Assertion: Security Token Assertion specifies what sort of security token is required and accepted by a web service or Web service client. This assertion is applicable to both the request and the response messages. As outlined in “Securing Web Services with WS-Security: Demystifying WS-Security, WS-Policy, SAML, XML Signature, and XML Encryption by Jothy Rosenberg, David Remy”, Security token assertion can be of much type like UserName Token assertion, X.509 Token assertion etc.
Integrity Assertion: Integrity Assertion specifies whether a SOAP message needs to be signed or not. It also specifies which parts of a SOAP message is to be signed and also which algorithm should be used to sign it. This assertion is applicable to both the request and the response SOAP messages.
Confidentiality Assertion: This assertion can be used by a Web service or its client to specify that parts of a request or a response SOAP message must be encrypted. This assertion can also specify how the encryption should be done, that means which encryption algorithm should be used for the encryption.
Visibility Assertion: The Visibility assertion allows an intermediary to require that a certain portion of the SOAP message be visible to it. Visible means either in the clear or encrypted in a way that the intermediary is able to decrypt limitation as described in “Securing Web Services with WS-Security: Demystifying WS-Security, WS-Policy, SAML, XML Signature, and XML Encryption by Jothy Rosenberg, David Remy”.
Message Age Assertion: The Message Age assertion is used to specify the time period, after which a message will be considered stale.
However, securing a web service using WS-Security Policy is no panacea. It is essentially a domain specific language, which selects cryptographic communications protocols and uses low-level mechanisms that build and check individual security headers. It gives freedom to invent new cryptographic protocols, which may be hard to get right, in whatever guise.
The specifications for web service security are evolving day by day with an immense speed. Although these specifications may not offer any new security protocol, they provide a framework that integrates existing security protocols to secure web service communication. Therefore, it may be necessary to identify whether these web service security specifications have achieved their security goals or not. This can be done by simulating different attack scenarios and verifying whether a security framework can guard against this attack. However, most of the time this brute force approach cannot reason about the security characteristics of a particular security framework. Because, the absence of a security flaw in a particular attack scenario does not specify that the security framework is not vulnerable in any other attack scenario. This type of reasoning regarding the security characteristics of a security framework can be achieved using formal methods. Therefore, formal methods are now applied to verify the security goals of web service security specifications. One of the earliest project that applied formal methods to verify the security goals of a web service security specification is Microsoft's SAMOA project.
All of those formalizations indeed may make some assumptions. One of the assumptions, which is indeed a limitation of these formalizations, is that a message can be read, written or modified by an attacker if the attacker knows the right key. Otherwise the attacker cannot perform the attack. However, it can be shown that this is not true for all sorts of attack. Moreover, a limitation of the above formalizations is that they may not model insider attacks.
A Web service may be a programmatic access to web sites. Therefore, it is vulnerable to the same kind of attack applicable to traditional web sites such as, DOS (Denial of Service), SQL Injection attack, etc. Moreover, as a web service uses XML data for exchanging messages, it may be vulnerable to another class of attack known as an XML rewriting attack, which occurs due to the structural weakness of XML data. An XML rewriting attack is a common name for a range of attacks such as, for example, replay, man-in-the-middle, redirection, and dictionary attack. The attacker exploits the flexibility of the SOAP security extensibility to capture, manipulate and replay SOAP messages without violating the integrity of the SOAP message. In the following, some attack scenarios in the context of a web service message exchange will be presented to better understand an XML rewriting attack.
A simple SOAP-based server that responds to requests for the latest prices of a list of airline tickets is considered. The server charges a subscriber's account for each request and does not wish to respond to non-subscribers. Therefore, it may require that a message signature generated using an X.509 certificate belonging to one of its subscribers authenticate each request. Moreover, it may require that each request includes a unique message identifier to be cached to detect a message replay.
Suppose a client wants to see the list of airline tickets. As the client is charged for each request it makes, the request contains a message ID, which is used by the server to keep track of client requests. Furthermore, the message ID of the request along with some other parts of the message are signed by the client using a X.509 certificate belonging to the client, which will help a corresponding server to authenticate the client and to check for the message integrity.
FIG. 1.1 shows the SOAP message that is sent by the client to the server. An attacker, sitting in between the client and the server intercepts the message. He then puts the <MessageID> header into another header <Irrelevant> and creates its own <MessageID> header with a new value. He then sends the message to the server.
FIG. 1.2 shows the message the attacker may send to the server after interception and modification.
The server on the other side, after receiving the message will try to validate the integrity of the message. It can be seen from FIG. 1.2, although the attacker has tampered on the message, he did it in a way so that the integrity of the message remains valid.
The scenario shown in FIG. 2.1 depicts how an XML rewriting attack can be used to redirect a SOAP request. Suppose a client wants to see the list of airline tickets. WS Addressing specifies a way for embedding the URI of the ultimate receiver through the use of a <To > element. FIG. 2.1 shows a request that the client sends to the airline ticket server with the URI of the server embedded into the request under the <To > element. The X.509 certificate of the client signs this <To > element. The request also uses a <From> element, specified in WS-Addressing to indicate the sender of the request. However, this element is not signed.
FIG. 2.2 shows the request modified and relayed by the attacker. The attacker simply puts the signed <To > element under an <Attack> element and introduced his own <To > element with a different URI. As it was seen in the previous example, with this modification of the attacker the integrity of the message will remain unchanged but the application logic will consider the <To > element introduced by the attacker instead of the <To > element that went into the <Attack> element and the message will be redirected to a different location instead of the location it was sent for.
According to WS-Security specification, a SOAP message can include more than one Security header. However, according to this specification no two Security headers can have the same role attribute value. As we saw before, the client includes a signed <MessageID> in the request message to help the server to keep track of the client request. The server caches the <MessageID> value. Whenever the server receives a request from the client, it tries to find the <MessageID> value in the cache. If it finds one, then it infers that someone, other than the intended client, has replayed the message and it will generate a SOAP fault. However, it is obvious that the cache has a limited capacity. The server has to delete cache entries after a certain amount of time. WS-Security also specifies a <Timestamp> header to indicate the server the time limit after which the server can delete the cache entries associated with the current request. FIG. 3 shows a client request with a signed <Timestamp> header.
FIGS. 3.1 and 3.2 depict how an attacker can exploit the flexibility of WS Security specification. When the client sends the message to the server, the attacker intercepts the message and waits until the <TimeStamp> value is expired. Then he creates a new Security header with role attribute's value “None” and “mustUnderstand” attribute's value “False”. Then he cuts the <TimeStamp> element from the original security header and puts it in the newly created security header. He then creates his own <Timestamp> header element and puts it under the original security header. Then he sends this message to the server. The SOAP processor on the server side will try to process the message and will ignore the Security header created by the adversary silently. Signature validation will also pass successfully as the Signature element references the <Timestamp> header element using XPointer, which does not take care of the location of the referenced element. Therefore, even though the attacker moved the <Timestamp> header element under a different <Security> header element it will resolve it as if it was not moved. Consequently, the SOAP processor will take the <Timestamp> element created by the attacker into account. As the server has deleted the cache of the client request due to the Timestamp expiration, it will not be able to find the <MessageID> of the attacker's message in its cache and will consider the request as a fresh request from the client. Therefore, the server will process the request as if it was sent from the intended client.
The attack scenarios presented in the last section do not cover all of the vulnerabilities that can arise in web service communication. Although simple at a first glance, an XML rewriting attack is not something that may be easily detected and removed. In the following, it is described some works done previously in order to get rid of this sort of attack.
If used correctly, WS-Security policy can act as a countermeasure against an XML rewriting attack. As explained before, web service operations are published using a WSDL file. This file contains the name of the operations the server offers and the input and output parameters required and produced by those operations. Security policy can be associated with these operations and/or with the input and output messages. These policies specify the security requirements of a web service. However, it is quite difficult to specify all possible security requirements in a WS-Security policy file. In “XML Signature Element Wrapping Attacks and Countermeasures by Michael McIntosh, Paula Austel from IBM research” the authors have shown different sort of rewriting attacks and the associated policy files for the detection of these attacks. They have also shown how an attacker can take advantages of a security policy hole in order to get unauthorized access to system resources. According to “XML Signature Element Wrapping Attacks and Countermeasures by Michael McIntosh, Paula Austel from IBM research” in practice the semantics of XML elements depends on its location. However, XML Signature provides for the referencing of an element independent of its location. They further showed that the flexibility that a SOAP header provides can be exploited by an attacker in a naïve way. The example shown in FIG. 4 is taken from “XML Signature Element Wrapping Attacks and Countermeasures by Michael McIntosh, Paula Austel from IBM research”.
FIG. 4.1 shows a client request to a stock quote application. This application takes a client request and returns the quote for the symbol specified as <getQuote@Symbol>. The request also includes a <ReplyTo> header element, which is specified in WS-Addressing. This element specifies where the response should be sent. Moreover, this <ReplyTo> element is optional. If it is not specified in the request, the response will be sent to the location from where the request has come.
FIG. 4.2 shows a sample security policy requirement of the stock quote application. It says that the request must contain a body element. This body element has to be referenced from the signature element that means the body element must be signed. The request may contain a <ReplyTo> element and if it contains a <ReplyTo> element then this <ReplyTo> element must be signed. Finally, it says that the signature must be verified using a X.509 certificate generated by a Certificate Authority (CA).
At first sight, it might seem that the security policy in FIG. 4.2 is sufficient for the stock quote application. But it may not be sufficient. FIG. 4.3 shows how an attacker can bypass the security requirements specified in FIG. 4.2 to redirect the response. As stated before, the <ReplyTo> header element is optional. Therefore, the attacker can intercept the client request shown in FIG. 4.1 and wrap up the <ReplyTo> header element by a <wrapper> element. This modification does not violate the security requirements of the application. The modified message of FIG. 4.3 contains a <Body> element, which is signed. It does not contain any <ReplyTo> element as it is now wrapped under a <wrapper> element and according to SOAP specification if a SOAP processor does not understand a header element it will ignore it silently. Therefore, when the stock quote application will receive the request of FIG. 4.3 it will discard the <wrapper> element. Moreover, a X.509 certificate generated by a CA can verify the signature. As all the security requirements are fulfilled, the application will process the message as if it was not tampered by an attacker and will send the response from where it got the request, in the above case to the attacker.
A deep investigation of the above scenario reveals the following reasons for this sort of vulnerabilities:
1) The SOAP Extensibility model and its processing rule allows optional header elements to be added to the header of a SOAP message. This feature provides for a better interoperability. Applications can use their own header element without any negotiation. On the other hand, this flexibility can be exploited by an attacker.
2) The reference from the signature element is using XPointer to reference the signed element, which does not take care of the location of the signed element.
In “XML Signature Element Wrapping Attacks and Countermeasures by Michael McIntosh, Paula Austel from IBM research”, they have proposed the use of Xpath expression for the removal of such an attack. This Xpath uses an absolute path of an element to reference it. FIGS. 4.4 and 4.5 show the request presented in FIG. 4.1 using Xpath for the reference and the new security requirements.
FIG. 4.6 shows a sample SOAP message that includes a Security header. This Security header among other information contains a signed Timestamp element. FIG. 4.7 shows a WS Security policy for the application server. In this policy, it is specified that the Timestamp element is optional. However, if it is present, then it must be signed. Moreover, it also specifies that the Timestamp element if present must be located under/soap:Envelope/soap:Header/wsse:Security. Now, if an attacker wraps up the Timestamp element under another fake element, the policy of the application server may easily detect it. Nevertheless, it still may be possible for an attacker to fool these policies. FIG. 4.8 shows how this can be accomplished.
In FIG. 4.8, the attacker created a new Security header, which conforms to the WS Security specification. However, according to WS Security specification, although a SOAP message, may contain multiple security headers, no two security header can have the same role attribute value. Therefore, the new Security header created by the attacker has a role attribute's value “none”. It means no SOAP node should process this header. Then the attacker cuts and pastes the Timestamp element from the existing Security header to the newly created Security header. After that, he/she created a new Timestamp element under the existing Security header.
When the SOAP processor on the receiver side will receive the SOAP message, it does not have any reason to make any complaint as the request fully conforms to the security policy. The Signature validator as well will find everything valid as the Xpath expression “/soap:Envelope/soap:Header/wsse:Security/wsu:Timestamp” will resolve to a set that will contain the signed Timestamp element. In “XML Signature Element Wrapping Attacks and Countermeasures by Michael McIntosh, Paula Austel from IBM research”, they have proposed to include not only the name of the parent element in the Xpath expression, but also some attribute values that will uniquely identify the parent of the signed element. For instance, instead of the path expression specified above, they proposed to use the following expression: “/soap:Envelope/soap:Header/wsse: Security[@soap:role=” . . . /ultimateReceiver”]/wsu:Ti mestamp”.
However, the above solution may not be enough to detect all rewriting attack that takes place using the above weakness of XML Digital Signature. Besides, they have mentioned two other sorts of context problems namely, a so-called Simple ancestry context problem and a so-called Sibling value context problem. The former type of problem occurs when the attacker changes the parent of a signed element. This problem may be detectable with Xpath referencing and WS Security policy. The sibling value context problem occurs if the application logic is dependent on the order of the signed elements. Then, the attacker can simply change the order of signed elements and this tampering will not get detected, as Xpath does not provide any information for the sibling of a signed element.
Microsoft's WSE or Web Service Enhancement is an implementation of many WS-specifications. It provides a library to create and process SOAP messages and headers. Many of the web services and their clients may be written and compiled using a strongly typed language. In “An Advisor for Web Services Security Policies by Karthikeyan Bhargavan, Cedric Fournet, Andrew D. Gordon, Greg O'Shea at Microsoft Research”, it is described that for the ease of parameter adjustment after the deployment of a web service, configuration files are used. These configuration files are loaded by the web service and their clients for the enforcement of the newly created or changed parameters without the recompilation of their code. In the case of WSE, WS-Security policy is part of this configuration file. It has already been shown that WS-Security policies may be vulnerable to an XML rewriting attack if not written correctly.
WSE Policy Advisor is a rule-based tool for detecting typical errors in WSE configuration and policy files. It takes the policy and configuration files of WSE, runs some static queries on them and generates security reports and remedial actions for security flaws. This tool has more than 30 queries. These queries check for some syntactic conditions of those policy files.
These syntactic conditions are determined by security reviews of the policy and configuration files of WSE. If these security conditions are not met by the policy files, the tool generates a report stating the threat that might occur due to this missing syntactic conditions. It also generates a remedial action that can be used by the author of the policy files to fix the flaw.
Although WSE Policy Advisor can detect errors that otherwise might be overlooked, it may have the following drawbacks:
i) WSE Policy Advisor does not provide any formal guarantees. It only provides a suggestion regarding possible flaws in policy configuration files found by running some queries.
ii) WSE Policy Advisor shows very poor performance if the policy configuration file becomes complex.
iii) The queries that are run by WSE-Policy Advisor may not detect possible existence of a signed element reordering attack.
In “Towards Secure SOAP Message Exchange in a SOA by Mohammad Ashiqur Rahman” and “An Inline Approach for Secure SOAP Requests and Early Validation by Mohammad Ashiqur Rahman” the author has proposed an approach for the detection of an XML rewriting attack. They have introduced a new header element called SOAP Account. This header element will keep different information of a SOAP message. The SOAP Account may include the following information of the SOAP message:
i) How many elements does the envelope of the SOAP message contain
ii) How many header elements are there in the header of the SOAP message
iii) How many signed elements are their in the SOAP message
iv) The immediate parent of each signed element
v) The successor of each signed element
vi) The siblings of each signed element
In conjunction with these elements, they have kept a field for future extensions in the SOAP account. They have created a module that before sending the SOAP message calculates the information necessary for the SOAP account and appends a SOAP account header element in the header or in the body of the SOAP message. As the SOAP message can pass through one or more intermediaries on its way to the ultimate receiver, the intermediaries are allowed to append its own SOAP account after the processing of the SOAP message. The author has imposed a restriction that the SOAP account must be signed by the creator using its X.509 certificate or by some other method. Each successive SOAP node must sign its own SOAP account concatenated with the signature of the previous node.
FIGS. 5.1 and 5.2 demonstrate how this SOAP account can be used to detect an XML rewriting attack on the SOAP message of FIG. 1.1. Whenever an attacker relocates the MessageID element of the SOAP message into an attack element, the structural information of the changed SOAP message does not match the information present in the SOAP account header element. Moreover, it may be required that the SOAP account must be signed. Therefore, the attacker cannot modify this SOAP account. Nevertheless, there is a possibility that the attacker can delete the SOAP account completely. To prevent this possibility the WS-Security policy can be used. This policy will check for the presence of a SOAP account header element. If it does not find one, it will generate error. That means, on the receiver side, a security policy must be present, which will check for the following:
i) SOAP account element is present under either the body element or the header element of the SOAP message.
ii) SOAP account element is signed which can be verified by a certificate issued by a trusted authority.
The approach presented here may detect a wide range of XML rewriting attacks. However, it may not detect all types of rewriting attacks that can take place. An analysis on this SOAP account approach can be summarized by the following points.
i) It does not include any mechanism to detect a replay attack. Although use of MessageID or Timestamp is proposed, it has to be considered the fact that these elements are optional. It is perfectly valid for a SOAP message to not include a MessageID or Timestamp. In that case, even though the SOAP message contains a SOAP account element, it is prone to an XML rewriting attack.
ii) The approach does not include any mechanism that can uniquely identify the parent of a signed element. Therefore, an attacker to gain unauthorized access to protected resources can use this unawareness of a SOAP account.
iii) The SOAP account itself is prone to an XML rewriting attack. It is specified that the receiver should check for the presence of the SOAP account element after receiving the SOAP message. However, as said before, the intermediaries can append its own SOAP account element in the SOAP message. Therefore, the number of SOAP account elements in a SOAP message is not fixed. For this reason, it is not possible to specify in security policy, how many SOAP account elements must be present in a SOAP message. The attacker can exploit this problem. He can just cut one of the several SOAP account elements of the SOAP message and paste it into a header element that is not signed and make the role attribute of the header element “None” and “mustUnderstand” attribute to false. Then, this header element will not be processed by the ultimate receiver or by any of the intermediaries. However, during the signature validation the reference of the relocated SOAP account element will be found as it is not removed but relocated.
iv) In a SOAP account element one of the fields is used to keep track of the siblings of a signed element. However, according to SOAP specification, an intermediary can append its own element in any place of a SOAP message. Therefore, this sibling information might change from node to node. It is not specified how this change can be detected by the ultimate receiver at the time of validation of the message.
v) In a SOAP account element, there is a field that keeps track of the successor of a signed element. However, this information does not have any role in the process of validation of a SOAP message. XML digital signature actually signs the digest value of an XML element. The digest value is calculated on the sub-tree rooted at the element that is to be signed. Therefore, if an element is signed all of its children are signed implicitly.
FIGS. 5.3 and 5.4 show how the SOAP account approach can become vulnerable to an XML rewriting attack. FIG. 5.3 shows a request SOAP message. This request contains the following:
i) A Timestamp element under the Security header. This element is signed.
ii) An Option element which is an Optional header element specific to some application.
iii) A Body element which is signed.
iv) A SOAP Account header element. This header element contains information regarding the SOAP message. Moreover, this header element is signed.
FIG. 5.4 shows how an attacker can modify the SOAP message and still keep the SOAP account information unchanged. He may do it in the following way:
i) He creates a role attribute for the Option header element and sets its value as “None”. He also creates a “mustUnderstand” attribute for the same header element and sets its value to “false”.
ii) Under this Option header element he creates a Security Element. He cuts and pastes the Timestamp element from the original Security header element to the newly created Security element.
iii) He then creates a BinarySecurityToken and a Signature element under the newly created Security header.
iv) He creates his own Timestamp element under the original Security header element.
When the above SOAP message will be received by the service provider, the SOAP Account validation module will try to verify the message. It will not be able to detect any tampering as none of the information that it contains has been changed. So, it will pass the message to the next step for Signature validation. This step will also pass successfully as the signed Timestamp element has not been removed instead it has been relocated. The SOAP processor will not process the Option header element as it has a role attribute value of “None” and the processor is not obliged to understand this header element as this element has a “mustUnderstand” attribute value of “false”. Therefore, the request will be processed normally and the attacker's target will be fulfilled.
It can be noted here that the above attack is not the only one that can be done to jeopardize the SOAP account security. As said before, the SOAP account itself is vulnerable to an XML rewriting attack. How it happens may be understood from FIGS. 5.3 and 5.4. However, it should be noted that the SOAP account itself could be vulnerable to an XML rewriting attack whenever a SOAP message contains multiple SOAP account header elements.
In the previous sections, different solutions proposed for the detection of an XML rewriting attack were presented. It was briefly explained how they work. However, it may be that the solutions may not properly remove an XML rewriting attack. While they are handling one sort of XML rewriting attack properly at the same time they may fail to take care of some other type of XML rewriting attack. The first solution, using Xpath expression with WS Security policy, can remove some XML rewriting attacks, but it may fail when there are multiple header elements with the same name under the header of the SOAP message. It also could not remove the sibling value-reordering problem, when the order of the signed elements is changed to perform an attack. The second solution, WS Policy Advisor, may be efficient in dealing with an XML rewriting attack. However, it also has shortcomings. The third solution, namely the SOAP account approach, may be able with a wide range of XML rewriting attacks, but it is also may be vulnerable in some cases.